Feat:(issue_2392) Single-value arguments can be marked as required - #2393

Issues to address

1. Duplicate enforcement with divergent error handling (moderate)

Required is checked in two places:

• checkRequiredArguments (command.go:457) — pre-parse path that prints Incorrect Usage: ... + help and sets isInError.
• ArgumentBase.Parse (args.go) — the arg-parsing loop only calls OnUsageError + handleExitCoder, with no help output and no isInError.

The Parse-level check is effectively dead code for the documented (required-first) ordering and only fires when a multi-value/variadic arg precedes a required arg. When it does fire, the error handling differs from the primary path (no help, different exit handling). Consider dropping one, or unifying the handling so both paths behave identically.

2. Index-based counting breaks with multi-value args (command.go:465)

index >= providedArguments assumes each declared argument consumes exactly one positional. I reproduced with:

Arguments: []Argument{
    &StringArgs{Name: "rest", Min: 0, Max: -1},
    &StringArg{Name: "required", Required: true},
}
cmd.Run(ctx, []string{"foo", "a", "b", "c"}) // → error: Required argument "required" not set

3 args are provided but the variadic consumes them all, so the arg genuinely receives no value — but the error is misleading. The docs do tell users to declare required args before optional/multi-value args, and the Parse backstop catches it, so acceptable — but worth a comment or an error message that hints at the ordering rule.

3. Missing builtInHelp || isCompletionCommand guard (command.go:457)

checkAllRequiredFlags (command.go:424) skips both; checkRequiredArguments doesn't. Currently harmless because --help short-circuits earlier via checkHelp() (command_run.go:215) and the built-in completion subcommands have no Arguments, but it's fragile if help/completion flow changes. Add the same guard for parity.

Minor / nits

• requiredArgument interface uses unexported methods (name(), required()), diverging from flags' public RequiredFlag pattern (flag.go:116). Custom third-party Argument implementations can never participate — fine, but inconsistent.
• Usage() now renders optional single args as [name] — a visible change to existing help output. It's consistent with ArgumentsBase and covered by the updated TestArgUsage, so I'd keep it, but it deserves the explicit release-note mention (which it has).
• Empty string ("") counts as "provided" — consistent with --flag "", fine.

Net: reasonable to merge after addressing #1 and considering #2/#3.